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PROCEDE D'ACCES A UN SERVICE A TRAVERS UN RESEAU D'ACCES 

MULTIVOIES 



La presente invention concerne un procede d'acces, a travers un 
reseau d'acces multivoies, d'un terminal a un service mis a disposition sur un 
reseau de communication par un fournisseur de services. 

L'invention trouve une application particulierement avantageuse dans 
5 le domaine de la fourniture de services, notamment sur le reseau Internet, 
lorsque I'acces au service est realise a travers un reseau d'acces multicanal 
ou a travers une pluralite dMnterfaces du terminal. On dit alors que I'acces au 
service se fait au travers d'un reseau d'acces « multivoies ». 

Bien que invention s'applique a tout type de reseau de 
10 communication, on se piacera dans la suite de ce memoire dans le cas du 
reseau Internet. Le service auquel le terminal cherche a acceder sera note 
service IP (Internet Protocol). 

Le cadre general de invention est done ceiui ou un fournisseur de 
services souhaite voir transporter un service IP comme, par exemple, une 
15 video en « stream » ou en telechargement, jusqu'a des terminaux clients 
connectes a un reseau d'acces IP multicanal ou a travers une pluralite 
d'interfaces du terminal vers des reseaux d'acces IP. On appellera « voie » 
indifferemment un canal d'un reseau d'acces multicanal ou une interface du 
terminal. 

20 Un reseau d'acces est appele, par la suite, reseau d'acces multicanal 

s'il contient soit un support physique avec plusieurs canaux logiques, soit 
plusieurs supports physiques. On appellera alors « canal » indifferemment un 
ensemble support physique/canal logique ou un des supports physiques. 

Parmi les reseaux d'acces multicanal connus, on peut citer le reseau 

25 DAB (Digital Audio Broadcasting) et le reseau DVB (Digital Video 
Broadcasting). 
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D'une maniere generate, le terminal-client decouvre le service IP 
aupres d'une fonction appelee « Offre de service ». Au prealable, les 
informations transmises par le fournisseur renseignent, aujourd'hui, un module 
de mediation, et done le terminal, sur la connexion IP, a savoir l'(es) 
adresse(s) IP associee(s) a un port TCP/UDP (Transfer Control Protocol/User 
Datagram Protocol)) et les caracteristiques de ('application a utiliser pour 
traiter un service donne, par exemple les caracteristiques de decodage pour 
un service video et les caracteristiques de Implication de telechargement. 

II faut noter que plusieurs connexions correspondant a plusieurs flux IP 
peuvent etre necessaires pour «consommer» un service IP donne, par 
exemple une connexion pour la video, une autre pour I'audio dans le cas' d'un 
service IP audio/video. Par la suite, on fera I'hypothese que le service IP ne 
contient qu'un flux IP. L'invention s'etend neanmoins par analogie au cas de 
plusieurs flux IP associes au service. 

S'agissant d'un acces a un service IP a travers un reseau multicanal, la 
description du service est habituellement faite par le fournisseur de services 
dans un fichier du type SDP (Service Description Protocol recommande par 
I'lETF (Internet Engineering Task Force)), mais n'inclut aucune information sur 
les caracteristiques du reseau d'acces multicanal a utiliser, notamment le 
canal (support physique/canal logique) a utiliser. 

Traditionnellement, on utilise les mecanismes de configuration de 
reseau du terminal (tables de routage, configuration reseau des interfaces) 
afin de trouver le chemin de communication vers un service IP donne. 
Cependant, dans le cas par exemple ou il n'y a pas de configuration reseau 
associee prealablement aux canaux logiques, comme e'est effectivement le 
cas des reseaux de diffusion DVB, DAB, ces techniques traditionnelles sont 
inoperantes. 

Neanmoins, pour eviter a I'utilisateur d'avoir a rechercher 
systematiquement le chemin de communication adequat vers le service IP 
parmi I'ensemble des canaux existants, les parametres de connexion au 
reseau d'acces doivent etre connus du terminal afin de s'accorder tout de 
suite sur le bon canal (couple support physique/canal logique). 
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Par exemple, ie fournisseur du service IP envoie son contenu au 
travers d'un reseau d'acces a une adresse IP notee @ associee a un port P. 
En parallele, le fournisseur du service IP presente au terminal, lors de la 
decouverte du service IP, la description de ce service en lui fournissant, par 
5 exemple pour un service multicast, !es informations @ et P et la nature de 
("application App a utiliser. 

Dans le cas d'un reseau d'acces multicanal de type DAB, les 
equipements du reseau d'acces (passerelles decapsulation IP dans des 
multiplex DAB) encapsulent le flux IP (@, P) dans un ensemble multiplex E, 
10 dans un sous-canal S de ce multiplex, et dans un paquet Pa de ce sous-canal. 

Le terminal ne peut se connecter au service IP (@, P) qu'a condition 
que sa configuration au reseau d'acces DAB corresponde aux parametres (E, 
S, Pa) choisis par Poperateur du reseau d'acces. 

Dans le cas d'un reseau d'acces multicanal DAB, la signalisation 
is envoyee aujourd'hui par les equipements du reseau d'acces utilise Tidentifiant 
(Service Id, Service component Ids), qu'on notera par la suite (Sid, SCIds), 
caracterisant de fagon unique une composante de service dans un reseau 
DAB, sachant qu'un flux IP donne est transports dans une composante unique 
de service. 

20 Get identifiant reste invariant quelles que soient les operations de 

multiplexage/remultiplexage. La signalisation du reseau d'acces DAB relie le 
couple (Sid, SCIds) aux supports physiques et aux canaux logiques utilises 
dans le systeme de transport DAB (ensemble E, sous-canal S, paquet Pa). 
Ainsi, a condition de connaTtre le couple (Sid, SCIds) associe a un service IP 

25 donne, le terminal peut connaTtre, via la signalisation re$ue du reseau 
d'acces, le canal (support physique/canal logique) de connexion au service IP 
desire. 

Aujourd'hui, I'utilisateur doit seiectionner manuellement de maniere 
empirique, ou de maniere statique par contrat, les parametres d'acces au 
30 reseau DAB, par exemple en selectionnant le nom du service DAB et le nom 
du "service component". 

Le terminal est alors accord e sur le bon support physique et le bon 
canal logique, ('extraction des donnees IP peut done se faire en accord avec 
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la description de service, concernant les informations de niveau appiicatif et la 
connexion IP, fournie par le fournisseur de services IP. 

Dans le cas d'un reseau multicanal DVB, une nouvelle table, dite table 
INT, a ete definie dans la specification ETSI EN 301 192 vl.3.1 '(2003-05). 
Cette table est mise a jour dynamiquement par les equipements du reseau 
DVB (passerelles decapsulation IP dans DVB, multiplexeur/remultiplexeur) 
et donne un lien entre les services IP encapsules (definis par exemple par les 
adresses IP destination et source) et le canal (support physique/canal 
logique) qui les transports. 

La decouverte par !e terminal du service IP est faite independamment. 
Neanmoins, une partie des informations de decouverte d'un service IP, 
notamment les caracteristiques de la connexion IP, comme les adresse IP 
destination et source, doivent etre renseignees dans la signalisation DVB afin 
d'effectuer un lien avec le canal d'acces. 

Toutefois, ces solutions connues proposees pour acceder a un service 
IP a travers un reseau d'acces multicanal presentent chacun un certain 
nombre d'inconvenients. 

Concernant le reseau DAB, on constate qu'aujourd'hui le client doit, 
dans deux operations separees et independantes, decouvrir, d'un cote, les 
services IP, et configurer ('interface de connexion au reseau d'acces! de 
I'autre. 

L'utilisation du reseau d'acces DAB pour transporter des services IP est 
recente et reste souvent experimentale. Un processus ou le client apprend de 
facon "statique" (au travers d'un contrat par exemple) sur quel canal DAB 
defini par le couple (Sid, SCIds) sont vehicuies les flux IP peut convenir. 

Dans un environnement plus dynamique, ('affectation d'un service IP a 
un couple (Sid, SCIds) peut ne pas etre connue en temps reel par le client. En 
outre, I'ergonomie d'une configuration manuelle peut rapidement etre 
inconfortable au cas ou le passage d'un service IP donne a un autre necessite 
quasiment systematiquement une reconfiguration de I'interface de connexion 
au reseau d'acces. 

Concernant le reseau DVB, la table INT de la signalisation DVB indique 
dynamiquement la localisation du service IP donne, mais le terminal doit 
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analyser de fagon croisee deux types de signalisation, a savoir les 
informations de decouverte de services et les informations de la table INT. 
L'identifiant caracterisant le service IP doit etre duplique dans les deux 
signalisations, entraTnant done une surcharge d'inforrnations alourdissant de 
fagon notable la signalisation DVB et augmentant aussi le temps d'analyse du 
terminal. 

Dans le cas d'un terminal ayant plusieurs interfaces de reseaux 
d'acces, une difficulty peut apparaTtre lors du choix de I'interface a laquelle le 
terminal du client devra se connecter pour recevoir un service IP multicast 
donne, a savoir le cas ou le service n'est accessible qu'au travers d'un reseau 
d'acces non previsible a priori par le terminal. 

Aussi, le probleme technique a resoudre par I'objet de la presente 
invention est de proposer un procede d'acces, a travers un reseau d'acces 
multivoies, d'un terminal a un service mis a disposition sur un reseau de 
communication par un fournisseur de services, qui permettrait, dans les cas 
ou I'acces a un service IP ne peut etre connue a I'avance par le terminal, par 
exemple si elle depend de la mise en oeuvre non predictibie du service IP 
dans un reseau d'acces multivoie, de fournir au terminal en meme temps que 
la decouverte du service IP (exemple dans un fichier SDP), les informations 
qui lui permettront de s'accorder automatiquement, et sans creation de tables 
chez Poperateur d'acces, sur le bon canal (support physique/canal iogique) du 
reseau d'acces ou la bonne interface a un reseau d'acces. Ces informations 
seront a jour au moment de ia decouverte de services. Si en outre on utilise 
un identifiant invariant dans le temps et dans Tespace, les informations 
transmises au moment de la premiere decouverte du service resteront a jour 
pendant toute la duree du service. 

La solution au probleme technique pose consiste, selon la presente 
invention, en ce que ledit procede d'acces comprend les etapes consistant : 
- pour le fournisseur de services, a fournir a un module de mediation des 
informations concernant au moins des donnees relatives a I'adresse dudit 
service dans le reseau de communication, 
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- pour le module de mediation, a determiner au moins un identifiant de voie a 
utiliser par le terminal pour acceder audit service, et a associer ledit identifiant 
de voie auxdites informations fournies par le fournisseur de services, 

- pour le terminal, a recevoir du module de mediation, lors de la decouverte du 
service, ledit identifiant de voie associe auxdites informations. 

Comme on le verra en detail plus loin, I'acces du terminal au service IP 
peut se resumer de la maniere suivante dans le cas, par exemple, de services 
IP multicast sur un reseau d'acces multicanal DAB. 

Dans une premiere phase, le fournisseur de services IP qui souhaite 
offrir un service aupres d'un operateur de reseau d'acces fournit a un module 
de mediation la description de son service qui comporte les elements que Ton 
trouve dans un fichier SDP standard, a savoir : 

- des informations de niveau applicatif, comme nom et description litterale du c 
service, date de diffusion du service, application necessaire pour decoder le- 
service, type de codecs, ... 

- des informations de niveau reseau, comme adresse IP multicast et port UDP 4 
necessaire pour communiquer avec le service IP multicast. t 

Si les informations de description de services ci-dessus ne suffisent £ 
pas a expliciter la demande de ressources, des informations complementaires -• 
sent ajoutees, comme par exemple I'identifiant du service auquel est associe 
le service IP, tel que le service France Inter sur DAB. 

Dans une deuxieme phase, le module de mediation, grace a la 
description du service fournie par le fournisseur de service IP, envoie des 
commandes vers Poperateur de reseau d'acces qui active les ressources de 
transport IP qui vont permettre de transporter le service IP dans un canal 
donne. Un exemple d'activation des ressources de transport IP est la 
commande des passerelles d'encapsulation de donnees IP dans le reseau 
d'acces en utilisant les elements caracterisant le service IP (adresse IP, port) 
et le canal de transport du service IP. Conformement a ('invention, la fonction 
de controle du reseau d'acces retourne au module de mediation le canal qui 
transportera le service IP. Le module de mediation associe alors I'information 
de canal aux autres informations recues du fournisseur de service. 
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Dans une troisieme phase, Ie client decouvre ie service au moyen de 
son terminal. L'information qu'il regoit par SDP par exemple contient au 
minimum: 

- les informations de niveau applicatif (codecs,...), 

5 - les informations de niveau reseau (adresse IP multicast, port), 

- et, conformement a ['invention, Ie lien avec Ie canal d'acces, par exemple 
ridentifiant Sid de service DAB et Pidentifiant SClds de la composante de 
service. 

Enfin, dans une quatrieme phase, Ie terminal se connecte au service IP 
10 a Paide de ces parametres. Dans Ie cas d'un reseau multicanal, Ie terminal 
s'accorde sur Ie canal correspondant auxdits parametres. Dans Ie cas d'une 
pluralite d'interfaces, Ie terminal peut configurer de fagon dynamique les 
parametres reseau du terminal et meme fournir aux applications ('interface 
reseau d'acces au service correspondant auxdits parametres. 
is La description qui va suivre en regard des dessins annexes, donnes a 

titre d'exemples non limitatifs, fera bien comprendre en quoi consiste 
('invention et comment elle peut etre realisee. 

La figure 1 est un schema d'un systeme de communication entre Ie 
serveur d'un fournisseur de services et un terminal, destine a la mise en 
20 oeuvre du precede d'acces conforme a ('invention. 

La figure 2 est un schema sur lequel sont representees les etapes du 
procede d'acces conforme a I'invention dans Ie cas du reseau d'acces DAB. 

La figure 3 est un schema sur lequel sent representees les etapes du 
procede d'acces conforme a [Invention dans Ie cas d'un acces du terminal au 
25 service IP a travers une pluralite d'interfaces. 

Le systeme de communication de la figure 1 est destine a permettre 
Pacces d J un terminal T, tel qu'un ordinateur personnel d'un client, a un service 
d'un fournisseur de services distribue par un serveur S de contenus IP a 
travers un reseau 2 de communication, par exemple le reseau Internet. 
30 Pour acceder au service IP souhaite, le terminal T utilise un reseau 1 

d'acces multivoies qui, dans la suite de la description, sera le reseau d'acces 
multicanal DAB. 
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En liaison avec le reseau 1, un systeme 3 abrite les interfaces de 
transfert vers le reseau d'acces multicanal (passerelles decapsulation de 
donnees IP sur support DAB par exemple) qui aiguilleront les flux de donnees 
IP sur un canal defini par un ensemble support physique/canal logique du 
reseau 1 d'acces. 

Eventuellement, le systeme 3 comporte des equipements de 
signalisation propres au reseau 1 d'acces. Cette signalisation optionnelle 
permet de donner les caracteristiques finales de localisation d'un service IP 
que le reseau 1 d'acces est parfois le seul a connaTtre. Dans I'exemple d'un 
service IP multicast transports sur un reseau d'acces DAB, le recours a la 
signalisation du reseau d'acces DAB est obligatoire : c'est elle qui fournira le 
lien entre un couple (Sid, SCIds) et le canal au sein des multiplex DAB . 

Le systeme 4 est un module de mediation qui abrite les fonctions de 
signalisation auxquelles fait appel le fournisseur S de services IP. Le module 
4 de mediation peut appartenir au fournisseur de services lui-meme ou une 
autre une entite tierce a laquelle il fait appel. 

Le systeme 5 abrite les fonctions de controle des ressources propres 
au reseau 1 d'acces multicanal. 

Le reseau 1b est facultatif. II permet au terminal T de dialoguer avec le 
module 4 de mediation par un autre reseau d'acces que le reseau 1 d'acces 
multicanal. Ce sera le cas par exemple lorsque le terminal T veut envoyer des 
messages vers le systeme 4 alors que le reseau 1 d'acces multicanal ne 
permet que la transmission des messages de ['interface 3 vers le terminal T. 
Cette situation se presente effectivement pour le reseau DAB qui est 
unidirectionnel dans le sens emetteur vers recepteur. 

Les echanges de donnees et d'informations au sein du systeme de 
communication de la figure 1 s'effectuent de la maniere suivante.. 

Les donnees echangees du serveur S de contenus IP vers le terminal T 
transitent par le reseau 2, puis ^interface 3 et le reseau 1 d'acces multicanal. 

Le module 4 de mediation dialogue avec le systeme 5 au travers du 
reseau 2. 

Le systeme 5 dialogue avec I'interface 3 au travers du reseau 2. 
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Le module 4 de mediation dialogue avec le terminal T au travers du 
reseau 2 puis du reseau 1 ou du reseau 1b. 

Les etapes du procede d'acces conforme a invention vont maintenant 
etre decrites en detail en regard de la figure 2 relativement a un acces 
multicanal. 

1.a - Le fournisseur de services IP souhaite distribuer son service IP 
jusqu'a des terminaux clients, tel que le terminal T. Pour cela, il fait appel au 
module 4 de mediation, Iequel peut etre sous-traite chez un tiers ou integre au 
serveur du fournisseur de services. Pour cela, ie fournisseur S fournit a la 
fonction "Description de services" du module 4 les elements de description de 
son service IP. 

Les elements fournis sont ceux que Ton trouve dans un fichier de 
description SDP (RFC 327 de IMETF) standard: a savoir: 

- des informations de niveau applicatif: nom et description litterale du service, 
date de diffusion du service, application necessaire pour decoder le service, 
type de codecs, etc, 

- des donnees de niveau reseau: adresse IP multicast et port UDP necessaire 
pour communiquer avec le service IP multicast. 

Si les informations de description de service ne suffisent pas a 
expliciter la demande de ressources, des informations complementaires sont 
ajoutees afin de completer le cas echeant Pappel a la demande de ressources 
effectuee lors de Petape l.b. Pour un service IP multicast sur DAB, ces 
informations complementaires sont, par exemple, le fait que le fournisseur de 
services souhaite diffuser son service sur une technologie DAB, le label du 
service radio auquel le service IP est rattache, la bande passante necessaire, 
la zone geographique ou le service sera opere, Poperateur de reseau d'acces 
souhaite, etc. 

La fonction "Description de services" du module 4 de mediation stocke 
la description du service dans la base de donnees du module. 

1.b - La fonction «Demande de ressources» du module 4 de mediation 
est informee de ['existence d'un nouveau service IP pour Iequel une demande 
de ressources est necessaire. La fonction «Demande de ressources» doit 
alors selectionner Poperateur de reseau 1 d'acces. 
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Elle doit ensuite selectionner les informations qui caracteriseront 
aupres de I'operateur du reseau 1 d'acces la demande de ressources: par 
example les adresses IP et port du flux IP, et un certain nombre d'elements 
complementaires comme la bande passante desiree. 

2. a - La fonction "Activation des ressources" du systeme 5 regoit la 
demande de ressources. 

2.b - Au cas ou la demande est recevable, par exemple si la bande 
passante necessaire est disponible dans les ressources d'acces DAB, ie 
systeme 5 envoie des ordres vers les equipements 3 de transfert afin que ie 
service IP puisse etre transports sur Ie reseau 1 d'acces dans un canal donne 
(physique donne et un canal logique donne). Les informations transmises aux 
equipements 3 sont celles qui caracterisent Ie service IP (exemple (adresse 
IP, port)) ainsi qu'une designation du support physique/canal logique sur' 
lequel devra etre vehicule Ie service IP. 

2. c - En reponse a la demande de ressources effectuee en 2. a, la 
fonction «Contr6le de ressources » du systeme 5 foumit I'identifiant permettant 
de determiner Ie canal qui sera utilise pour transporter Ie service IP sur Ie 
reseau 1 d'acces multicanal. Par la suite, ce champ sera appele « identifiant 
de localisation du canal dans Ie reseau d'acces ». En DAB, cet identifiant ' 
represente Ie couple (Sid, SCIds). 

3. a - La fonction "Demande de ressources" du module 4 de mediation 
met a jour la base de donnees du module en associant aux informations de 
description du service IP Ie champ « identifiant de localisation du canal dans 
le reseau d'acces ». 

3.b - La fonction "Off re de services" du module 4 est informee qu'elle 
doit creer un fichier de decouverte de services associe au service IP. Si la 
decouverte de services est faite au travers d'un fichier SDP, ce fichier 
contiendra les champs presents dans la base de donnees et regus par la 
fonction decouverte de services (champs d'un fichier SDP standard) et le 
nouveau champ « identifiant de localisation du canal dans le reseau 
d'acces ». Ce champ est place dans une description SDP de niveau media, au 
cas ou il y aurait plusieurs medias et done plusieurs flux IP associes au 
service IP. 
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4.a - Le terminal client T par sa fonction "Decouverte de services" 
decouvre le service IP : 

- soit en envoyant une requete aupres de la fonction "Offre de services" du 
module 4, en telechargeant par exemple le fichier SDP sur un serveur WEB 
mis a jour par la fonction "Offre de services" du module 4, 

- soit par I'envoi des informations par la fonction "Offre de services" vers le 
terminal T au travers d'un protocole comme SAP/SDP (RFC 2974). 

4.b - La fonction "Invocation de service", qui peut etre sollicitee au 
moment ou I'utilisateur selectionne sur I'interface graphique du terminal T ie 
service IP (die sur un icone par exemple), traite le fichier de decouverte de 
services (fichier SDP par exemple), et done le champ « identifiant de 
localisation du canal dans le reseau d'acces ». 

4.c - La fonction "Invocation de service" du terminal T lance 
I'application en lui fournissant les parametres presents dans le fichier de 
decouverte de services et qui lui sont necessaires. Grace aux parametres de 
communication IP (classiquement adresse(s) IP et port), I'application ouvre la 
connexion IP. 

4.d - La fonction "Invocation de service" communique par une interface 
de type API avec la carte du terminal de connexion au reseau 1 d'acces et lui 
fournit les parametres presents dans le champ « identifiant de localisation du 
canal dans le reseau d'acces ». 

Au niveau de la carte de connexion au reseau 1 d'acces, le recours a 
une analyse de la signalisation est optionnelle, mais obligatoire dans le cas 
d'un reseau DAB. 

Au moment ou la carte du terminal T est accordee sur le bon canal 
(support physique/canal logique), les donnees IP issues du serveur S de 
services au travers des equipements du reseau 1 d'acces physique sont 
recues par la carte de reception du terminal T et traitees par I'application 
desiree (lecteur de video par exemple). 

Les etapes du procede d'acces conforme a ('invention vont maintenant 
etre decrites en detail en regard de la figure 3 relativement a un acces 
multiinterfaces. 
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On decrit ici I'exemple de diffusion du service IP multicast sur un 
reseau d'acces DAB, le terminal pouvant recevoir potentiellement des 
services multicast sur plusieurs interfaces reseaux correspondant a des 
technologies differentes. 

1.a - Le fournisseur de services IP souhaite distribuer son service IP 
jusqu'a des terminaux clients, tel que le terminal T. Pour cela, il fait appei au 
module 4 de mediation, lequel peut etre sous-traite chez un tiers ou integre 
chez le fournisseur de service. Pour cela, le serveur S foumit a la fonction 
"Description de services" du module 4 les elements de description de son 
service IP. 

Les elements fournis sont ceux que Ton trouve dans un fichier de 
description SDP (RFC 327 de I'lETF) standard: a savoir: 

- des informations de niveau applicatif: nom et description litterale du service, 
date de diffusion du service, application necessaire pour decoder le service,' 
type de codecs, etc, 

- des donnees de niveau reseau: adresse IP multicast et port UDP necessaire ? 
pour communiquer avec ie service IP multicast. 

En plus des informations de description de service, le fournisseur de * 
services foumit, s'il y a lieu, ses preferences en terme de technologie reseau 1 
d'acces (exemple : si possible DAB, sinon DVB) et d'autres informations 
complementaires afin de completer le cas echeant la demande de ressources 
effectuee en 1.b, par exemple pour un service IP multicast desire sur une 
technologie DAB : le label du service radio auquel le service IP est rattache, 
la bande passante necessaire, la zone geographique ou le service sera' 
opere, I'operateur de reseau d'acces souhaite, etc. 

La fonction "Description de services" du systeme 4 stocke la 
description du service dans la base de donnees du systeme. 

1.b - La fonction «Demande de ressources» du module 4 de mediation 
est informee de I'existence d'un nouveau service IP pour lequel une demande 
de ressources est necessaire. La fonction «Demande de ressources» doit 
alors selectionner ia technologie du reseau d'acces, voire I'operateur de 
reseau d'acces. Le choix definitif de la technologie du reseau d'acces peut 
etre fait en fonction des choix du fournisseur de services, des regies comme 
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les contrats avec des operateurs d'acces, des informations de charge de 
reseaux d'acces, des facteurs de cout 

II faut noter qu'un meme service IP peut etre transporte simultanement 
sur plusieurs reseaux d'acces de technologie differente, par exemple les 
5 signalisations DAB et DVB. Dans ce cas, on peut envisager que le module 4 
de mediation etablisse un ordre de priorite des differentes technologies, ie 
terminal T se voyant imposer cette priorite. Une autre solution consiste en ce 
que la priorite est definie par le terminal T tui-meme. 

La fonction «Demande de ressources» doit ensuite selectionner les 
10 informations qui caracteriseront aupres de I'operateur du reseau 1 d'acces la 
demande de ressources: par exemple les adresses IP et port du flux IP, et un 
certain nombre d'elements complementaires com me la bande passante 
desiree. 

2. a - La fonction "Activation des ressources" du systeme 5 regoit la 
15 demande de ressources. 

2. b - Au cas ou la demande est recevable, par exemple si la bande 
passante necessaire est disponible dans les ressources d'acces DAB, le 
systeme 5 envoie des ordres vers les equipements 3 de transfer! afin que le 
service IP puisse etre transporte sur le reseau d'acces. 

20 2.c - En reponse a la demande de ressources effectuee en 2. a, la 

fonction «Contr6Ie de ressources» confirme ('attribution des ressources. 

3. a - La fonction "Demande de ressources" du systeme 4 met a jour la 
base de donnees du systeme en ajoutant a la description du service IP le 
champ "technologie du reseau d'acces" qui definit la technologie du reseau 

25 d'acces employee, ou des reseaux d'acces employes accompagnes 
eventuellement de la priorite associee, s'il y en a plusieurs reseaux d'acces 
possibles comme indique en 1.b. Pour le cas d'un reseau d'acces DAB, ce 
champ sera egal par exemple a «DAB». 

3.b - La fonction "Offre de services" du module 4 est informee qu'elle 

30 doit creer un fichier de decouverte de services associe au service IP. Si la 
decouverte de services est faite au travers d'un fichier SDP, ce fichier 
contiendra les champs presents dans la base de donnees et regus par la 
fonction decouverte de services (champs d'un fichier SDP standard) et le 
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nouveau champ « technologie du reseau d'acces ». Ce champ est place dans 
une description SDP de niveau media, au cas ou il y aurait plusieurs medias 
et done plusieurs flux IP associes au service IP. 

4.a - Le terminal client T par sa fonction "Decouverte de services" 
decouvre le service IP : 

- soit en envoyant une requete aupres de la fonction "Offre de services'* du 
module 4, en telechargeant par exemple le fichier SDP sur un serveur WEB 
mis a jour par la fonction "Offre de services" du module 4, 

- soit par I'envoi des informations par la fonction "Offre de services" vers le 
terminal T au travers d'un protocole comme SAP/SDP (RFC 2974). 

4.b - La fonction "Invocation de service", qui peut etre sollicitee au 
moment ou I'utilisateur selectionne sur I'interface graphique du terminal T le 
service IP (die sur un icone par exemple), traite le fichier de decouverte de 
services (fichier SDP par exemple), et done le champ « technologie du reseau 
d'acces ». 

4.c - La fonction "Invocation de service" du terminal T lance 
I'application en lui fournissant les parametres presents dans le fichier de 
decouverte de services et qui lui sont necessaires. Grace aux parametres de 
communication IP (classiquement adresse(s) IP et port), I'application ouvre la 
connexion IP. 

4.d - La fonction "Invocation de service" fournit a la fonction "Choix de 
I'interface du reseau d'acces" Indication que le service IP d'adresse @ doit 
etre obtenu au travers d'une interface du terminal T correspondant au champ 
"technologie du reseau d'acces". Pour I'exemple d'un service IP multicast, la 
fonction « Choix de I'interface du reseau d'acces » modifie les parametres de 
configuration reseau du terminal, de facon a ce que I'abonnement multicast 
soit fait sur 1'interface appropriee correspondant aux priorites definies par le 
module 4 de mediation ou localement par le terminal T. A noter qu'une autre 
possibilite pour les services IP multicast serait que la fonction "Lancement de 
I'application" identifie I'interface a laquelle I'application devra elle-meme 
s'abonner pour consommer le service IP, en fonction du champ « technologie 
du reseau d'acces » fourni par la fonction « Invocation de service ». 
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Une fois realisee la selection de ('interface du reseau d'acces d'une 
maniere ou d'une autre, ies donnees IP issues du serveur S au travers des 
equipements du reseau 1 d'acces physique sont regues par la carte de 
reception du terminal T et traitees par Pappiication desiree (lecteur de video 
5 par exemple). 

A noter que Ies cas « multicanal » et « multiinterfaces » peuvent etre 
cumulatifs ; si le reseau d'acces defini par le module de mediation est 
multicanal, Pidentifiant de canal sera transmis au terminal iors de la 
decouverte de services en meme temps que Pidentifiant de voie. La fonction 
10 « Choix de (Interface du reseau d'acces » retaiera alors vers la bonne 
interface du reseau d'acces multicanal Pidentifiant du canal. 



15 



1 er depot 

16 



REVENDICATIONS 



1. Procede d'acces, a travers un reseau (1) d'acces multivoies, d'un terminal 
(T) a un service mis a disposition sur un reseau (2) de communication par un 
fournisseur de services, 

caracterise en ce que ledit procede d'acces comprend les etapes consistant : 

- pour !e fournisseur de services, a fournir a un module (4) de mediation des 
informations concernant au moins des donnees relatives a I'adresse (@, P) 
dudit service dans le reseau (2) de communication, 

- pour le module (4) de mediation, a determiner au moins un identifiant de voie 
a utiliser par ie terminal (T) pour acceder audit service, et a associer ledit 
identifiant de voie auxdites informations fournies par le fournisseur (S) de 
services, 

- pour le terminal (T), a recevoir du module (4) de mediation, lors de la 
decouverte du service, ledit identifiant de voie associe auxdites informations. 

2. Procede selon la revendication 1, caracterise en ce que, le reseau d'acces 
multivoies etant un reseau d'acces multicanal, ledit identifiant de voie 
comprend, au moins, un identifiant de localisation du canal a utiliser par le 
terminal dans ledit reseau d'acces multicanal. 

3. Procede selon la revendication 2, caracterise en ce que le module (4) de 
mediation determine le reseau (1) d'acces multicanal a utiliser, et recoit dudit 
reseau d'acces ledit identifiant de localisation. 

4. Procede selon I'une des revendications 2 ou 3, caracterise en ce que ledit 
reseau d'acces multicanal est un reseau utilisant la signalisation DVB. 

5. Procede selon I'une des revendications 2 ou 3, caracterise en ce que ledit 
identifiant de canal comprend en outre un identifiant de la technologie dudit 
reseau d'acces multicanal. 

6. Procede selon la revendication 5, caracterise en ce que ledit reseau 
d'acces multicanal est un reseau utilisant la signalisation DAB. 

7. Procede selon la revendication 6, caracterise en ce que ledit identifiant de 
canal est constitue par le couple Sid, SCIds. 
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8. Precede seion Tune quelconque des revendications 2 a 7, caracterise en ce 
que ledit terminal (T) s'accorde sur le canal correspondant audit identifiant de 
voie. 

9. Procede seion la revendication 1, caracterise en ce que, le reseau d'acces 
5 muitivoies etant constitue par une pluralite d'interfaces du terminal a des 

reseaux d'acces, ledit identifiant de voie est un identifiant d'au moins une 
technologie a utiliser. 

10. Procede seion la revendication 9, caracterise en ce que ie module (4) de 
mediation determine la technologie d'acces a utiliser. 

10 11. Procede seion la revendication 10, caracterise en ce que, en cas de 
pluralite de technologies aptes a etre utiiisees, le module (4) de mediation 
definit une priorite desdites technologies. 

12. Procede seion la revendication 10, caracterise en ce que, en cas de 
pluralite de technologies aptes a etre utiiisees, le terminal (T) definit une 

is priorite desdites technologies. 

13. Procede seion Tune quelconque des revendications 10 a 12, caracterise 
en ce que, en cas de pluralite d'interfaces pour une technologie donnee, le 
terminal (T) determine ('interface a utiliser. 

14. Procede seton Tune quelconque des revendications 9 a 13, caracterise en 
20 ce que ledit terminal (T) se connecte sur ['interface reseau correspondant 

audit identifiant de voie. 

15. Precede seion i'une quelconque des revendications 1 a 14, caracterise en 
ce que ies informations regues par le module (4) de mediation provenant du 
fournisseur de service concernent egalement des donnees relatives au 

25 service. 

16. Systeme d'acces, a travers un reseau (1) d'acces muitivoies, d'un terminal 
(T) a un service mis a disposition sur un reseau (2) de communication par un 
fournisseur de services, 

caracterise en ce que ledit systeme d'acces comprend un module (4) de 
30 mediation apte : 

- a recevoir du fournisseur de services des informations concernant au moins 
des donnees relatives a I'adresse (@, P) dudit service dans le reseau (2) de 
communication, 
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- a determiner au moins un identifiant de voie a utiliser par le terminal (T) pour 
acceder audit service, et a associer ledit identifiant de voie auxdites 
informations fournies par ie fournisseur (S) de services, 

- a fournir au le terminal (T), lors de la decouverte du service, ledit identifiant 
de voie associe auxdites informations. 

17. Systeme d'acces selon la revendication 16, caracterise en ce que le 
reseau d'acces etant un reseau d'acces multicanal, le module (4)'de 
mediation est apte a determiner le reseau (1) d'acces multicanal a utiliser, et 
recoit dudit reseau d'acces un identifiant de localisation du canal a utiliser par 
le terminal (T). 

18. Systeme d'acces selon la revendication 16, caracterise en ce que, le 
reseau d'acces multivoies etant constitue par une pluralite d'interfaces du 
terminal a des reseaux d'acces, le module (4) de mediation est apte a 
determiner la technologie d'acces a utiliser. 

19. Systeme d'acces selon I'une quelconque des revendications 16 a 18 
caracterise en ce que ledit terminal (T) est apte a s'accorder sur le-cana'l 
correspondant audit identifiant de voie. • 

20. Systeme d'acces selon I'une quelconque des revendications 16':; a 18 
caracterise en ce que ledit terminal (T) est apte a se connecter sur ('interface 
reseau correspondant audit identifiant de voie. 

21. Module de mediation pour un systeme d'acces, a travers un reseau (1) 
d'acces multivoies, d'un terminal (T) a un service mis a disposition sur un 
reseau (2) de communication par un fournisseur de services, 

caracterise en ce que ledit module (4) de mediation est apte': 

- a recevoir du fournisseur de services des informations concernant au moins 
des donnees relatives a I'adresse (@, P) dudit service dans le reseau (2) de 
communication, 

- a determiner au moins un identifiant de voie a utiliser par le terminal (T) pour 
acceder audit service, et a associer ledit identifiant de voie auxdites 
informations fournies par le fournisseur (S) de services, 

- a fournir au le terminal (T), lors de la decouverte du service, ledit identifiant 
de voie associe auxdites informations. 
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22. Module de mediation selon la revendication 21, caracterise en ce que, le 
reseau d'acces etant un reseau d'acces multicanal, le module (4) de 
mediation est apte a determiner le reseau (1) d'acces multicanal a utilises et 
regoit dudit reseau d'acces un identifiant de localisation du canal a utiliser par 

5 le terminal (T). 

23. Module de mediation selon la revendication 21, caracterise en ce que, le 
reseau d'acces multivoies etant constitue par une pluralite d'interfaces du 
terminal a des reseaux d'acces, le module (4) de mediation est apte a 
determiner la technologie d'acces a utiliser. 
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